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Software  and  information  technology  service  providers  and  Department  of  Defense  ac¬ 
quisition  programs  face  common  problems  and  share  common  goals.  The  software  and 
services  industry  must  deliver  solutions  that  meet  customer  needs  cost  effectively  while 
providing  a  profit  margin;  and  DoD  programs  need  software  solutions  that  meet  cost, 
schedule,  and  performance  objectives.  The  drive  to  achieve  those  goals  has  spurred  pro¬ 
cess  and  development  initiatives  in  industry  and  DoD,  with  each  entity  leveraging  the  advances 
in  the  other.  This  continuous  search  for  improvement  is  as  much  a  journey  as  a  destination,  as  we 
examine  new  opportunities  for  improving  the  quality,  cost,  and  timeliness  of  software  capabilities. 

Trends  in  Software  Product  and  Project  Development 

Software  product  and  project  development  have  always  presented  challenges  for  both  industry  and  DoD  software 
acquisition  in  meeting  cost,  schedule,  and  quality  objectives.  Organizations  are  in  constant  search  of  management 
systems  that  address  these  challenges.  One  shift  industry  has  made  to  ensure  high  quality-product  and  project 
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deliverables  is  to  emphasize  the  importance  of  the  software 
development  process  and  to  rely  on  capability  maturity  model 
integration  (CMMI)  levels  to  measure  software  development 
organizations.  Software  development  organizations  have  fo¬ 
cused  on  repeatable  processes,  continuous  improvement,  and 
feedback  systems  to  benchmark  and  improve  their  CMMI 
levels.  Software  acquisitions  in  weapons  systems  programs 
facing  the  same  issues  have  leveraged  the  industry  trends 
and  have  integrated  the  use  of  CMMI  measures  in  software 
acquisitions  and  in  the  selection  and  evaluation  of  software 
development  organizations. 

A  second  critical  aspect  in  improving  software  deliverables  is 
requirements  management.  Changing  requirements  have  long 
been  recognized  as  a  root  cause  of  programs  not  meeting  cost, 
schedule,  and  performance  requirements,  even  as  programs 
bravely  attempt  to  resist  requirements  creep  and  struggle  to 
identify  valid  requirements  changes.  Industry  has  responded 
to  this  issue  by  emphasizing  robust  requirements  manage¬ 
ment  with  sophisticated  tools  and  implementing  rigorous 
configuration  management  of  requirements.  Traceability  ma¬ 
trices  are  used  to  map  software  requirements  to  stakeholder 
requirements  and  systems  functions.  Traceability  provides  a 
mechanism  of  checks  and  balances  to  ensure  requirements 
changes  are  evaluated  critically  and  accepted  with  a  complete 
analysis  of  their  impact.  The  process  is  taken  to  the  next  step 
and  extended  further  when  systems  development  is  based  on 
coupling  requirements  management  with  the  development  of 
business-  and  system-use  cases,  again  to  efficiently  and  ef¬ 
fectively  manage  the  system  development  process. 

The  Defense  Department  has  emphasized  the  same  systems 
management  principles  in  the  systems  engineering  processes 
that  govern  weapons  systems  development.  While  DoD  does 
not  prescribe  a  process  to  external  suppliers,  weapons  sys¬ 
tems  developers  are  evaluated  on  the  use  of  documented 
industry  standard  systems  engineering  processes,  with  their 
effectiveness  typically  reflected  in  their  past  performance  and 
deliverables. 

The  software  industry  business  model  was  based  on  requir¬ 
ing  a  significant  investment  of  research  and  development 
dollars  in  software  products  with  the  hope  of  delivering  the 
same  product  many  times,  with  minor  customization  for  indi¬ 
vidual  customers.  This  industry  model  appears  to  be  restricted 
to  large-infrastructure  software  capabilities  in  the  realm  of 
databases,  enterprise  applications,  and,  perhaps,  the  social 
networking  platforms  of  the  current  era;  and  is  dominated  by 
a  few  large  players.  The  need  for  and  dream  of  mass  custom¬ 
ization  of  software  products  continue,  however,  driven  by  the 
mantra  "build  once  and  reuse  and  recombine  many  times," 
so  as  to  deliver  customized  software  business  solutions  that 
meet  individual  customers'  unique  needs. 

This  need  and  the  mantra  are  now  close  to  being  realized  with 
the  third  trend  in  the  software  industry  of  developing  software 
as  reusable  services.  The  basic  concept  is  to  develop  services 


that  implement  common  functionality  that  can  be  reused  by 
many  software  applications.  An  example  is  the  creation  of 
a  service  that  authenticates  users  when  they  sign  on  to  an 
application  using  smart  cards  and  user-specific  information. 
This  service  can  be  used  when  authenticating  remote  users  in 
an  application  that  supports  remote  access  or  in  an  applica¬ 
tion  that  supports  users  when  they  are  present  in  person— a 
common  service  used  in  two  applications.  As  new  custom¬ 
ers  or  new  customer  needs  emerge,  existing  services  can  be 
recombined  along  with  the  development  of  new  services  to 
deliver  customized  solutions.  The  new  services  developed  in 
a  specific  engagement  are  added  to  the  pool  of  existing  ser¬ 
vices  and  reused  yet  again  in  the  next  customer  engagement. 
The  advantages  are  obvious:  development  of  new  software 
on  a  specific  engagement  is  minimized  and  limited  to  any  new 
services  required  for  the  engagement.  A  unique  customer  so¬ 
lution  to  address  the  customer's  specific  problem  is  crafted 
using  existing  and  new  services.  Thus,  we  see  many  software 
companies  becoming  services  companies  and  using  services 
to  deliver  customized  solutions,  a  transformation  made  pos¬ 
sible  by  this  trend. 

Over  the  years,  this  approach  has  been  used  in  software  devel¬ 
opment,  but  the  difference  this  time  has  been  the  emergence 
of  the  Internet  as  the  driving  and  governing  force  of  industry 
standards  for  services.  These  standards  have  supported  all 
aspects  of  software  services  development,  including  the  use 
of  communication  protocols  and  the  encapsulation  of  data. 
The  approach  is  not  intended  to,  and  does  not,  eliminate  the 
development  of  efficient  algorithms  or  innovation  in  imple¬ 
mentation;  instead  it  allows  the  software  development  process 
to  focus  on  precisely  this  innovation  and  the  efficient  use  of 
technology  and  less  on  the  rules  governing  the  process. 

An  Opportunity  for  DoD 

DoD  has  recognized  this  trend  towards  services-oriented 
architecture  and  acknowledged  it  in  the  DoD  Architecture 
Framework  as  a  key  tenet  of  DoD's  Net-Centric  Data  strategy. 
A  conceptual  approach  to  how  DoD  can  leverage  the  develop¬ 
ment  and  reuse  of  services  not  only  in  weapons  systems  ac¬ 
quisition  but  in  all  automated  information  systems  acquisitions 
is  outlined  here.  The  first  step  in  the  process  is  the  identifica¬ 
tion  of  required  services.  This  step  would  involve  reviewing 
the  DoD  architecture  framework,  net-ready  key  performance 
parameters,  and  other  sources  of  common  software  require¬ 
ments  to  develop  a  set  of  generally  accepted  software  services 
that  have  been  or  will  be  used  in  DoD  programs.  It  would  also 
require  the  development  of  a  common  services  development 
framework  (CSDF)  that  would  be  applicable  to  DoD  software 
development  and  software  acquisitions.  The  next  step  would 
be  to  identify  software  capabilities  for  which  DoD  has  acquired 
data  rights  and  to  review  those  capabilities  in  order  to  develop 
a  library  of  services  that  could  be  reused  for  planned  software 
capabilities.  The  library  of  services  might  need  to  be  re-engi- 
neered  to  adhere  to  the  CSDF.  The  initial  set  of  services  could 
include  standard  integration  services  between  major  informa¬ 
tion  backbone  networks  currently  implemented  in  DoD.  The 
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CSDF  would  be  a  published  framework  for  software  suppliers 
and  industry  to  use  in  responding  to  DoD  requirements.  Over 
time,  the  framework  could  migrate  to  be  accepted  as  an  indus¬ 
try  standard  and  managed  using  industry  standards  groups. 

The  next  step  would  be  to  expand  the  initial  library  of  services 
with  additional  or  new  services  required  by  DoD  acquisitions. 
The  process  would  require  that  DoD  solicitations  include  the 
library  of  services  that  suppliers  could  access  to  develop  their 
responses.  This  library  of  services  would  be  made  available  to 
suppliers  (with  limited  data  rights  to  protect  DoD  intellectual 
property).  Suppliers  would  also  have  access  to  the  CSDF,  and 
their  responses  should  identify  the  new  services  that  are  in¬ 
cluded  in  their  proposal.  DoD  would  also  acquire  data  rights 
to  the  new  services,  and  those  services  would  be  added  to 
the  library  of  services.  The  logical  extension  of  the  model  is  a 
robust,  growing  set  of  services  that  could  be  reused  for  future 
acquisitions  across  the  DoD  enterprise. 

The  benefits  of  the  approach  described  above  would  be  signifi¬ 
cant.  The  cost  of  new  software  development  would  be  reduced 
over  time  as  the  library  of  services  grew  and  services  were 
reused.  Additional  benefits  would  be  gained  in  reduced  test 
effort  as  services  previously  tested  required  less  test  effort  in 
future  implementations.  The  quality  of  the  resultant  software 
capability  would  be  higher  as  the  percentage  of  tested  and 
proven  services  increased  in  the  delivered  capability.  A  life 
cycle  benefit  would  be  reduced  support  costs  because  the 
system  would  be  built  around  services  currently  supported  and 


new  development  would  be  minimized.  The  net  result  should 
be  a  lower-cost,  higher-quality  capability  that  meets  de¬ 
sired  time  frames. 

W  Meeting  DoD’s  Unique 

Requirements 

DoD  has  unique  requirements.  Fore¬ 
most  are  security  requirements,  and 
there  are  several  approaches  that  can 
be  evaluated  to  ensure  DoD  systems 
remain  well  protected.  The  specific  algo¬ 
rithms  and  methods  to  protect  data  would 
not  be  exposed  to  external  suppliers.  All  of 
the  mechanisms  currently  in  place  to  protect 
secure  data  would  continue  to  be  applied  in 
shared  services  implementations.  The  library 
of  services  provided  to  suppliers  during  solicita¬ 
tions  would  exclude  targeted  security  services; 
however,  those  services  would  be  provided  to  suppliers  once 
they  had  been  selected,  and  the  current  strict  guidelines  that 
are  used  to  share  secure  information  with  external  suppliers 
would  continue  to  be  enforced.  Another  approach  could  re¬ 
quire  the  development  and  support  of  security  services  to  be 
under  the  purview  of  DoD  software  development  organiza¬ 
tions.  The  services  could  be  made  available  as  government- 
furnished  software  "black  box"  modules.  External  entities 
would  have  no  access  to  the  content  or  implementation  of 
those  services— integration  testing  could  be  restricted  to 
DoD  organizations. 

Another  important  aspect  of  services-based  solutions— 
and  even  more  so  in  DoD  systems— is  system  performance. 
Services  implementations  generally  require  robust  networks 
and  system  resources  to  achieve  the  required  performance; 
DoD  systems  are  developed  with  high-performance  require¬ 
ments  and  around  a  robust  infrastructure.  This  core  compe¬ 
tence  in  high-performance  systems  positions  DoD  to  take 
a  leadership  role  in  optimizing  services  implementations 
for  improved  performance  and  transfering  the  knowledge 
to  industry,  thereby  continuing  the  symbiotic  relationship 
between  industry  and  DoD. 

The  DoD  acquisition  framework  has  provided  the  blueprint 
for  systems  development  and  delivery  of  high-performance 
systems  that  need  to  be  sustained  for  many  years.  Driven 
by  market  necessities,  industry  has  been  agile  in  improving 
processes  and  moving  software  development  technologies 
forward.  The  two  paths  have  intersected  and  leveraged  the 
best  practices  of  both  in  the  search  for  cost-effective,  best- 
of-breed  solutions.  The  journey  continues  as  services-based 
implementation  opportunities  are  explored  for  integration  into 
DoD  systems  development. 

Rao  is  a  DAU  professor  of  acquisition  management.  His  industry  back¬ 
ground  includes  program  management  of  hardware  and  application  solu¬ 
tions  along  with  business  process  consulting  that  leveraged  technology- 
based  solutions.  The  author  welcomes  comments  and  questions  and  can 
be  contacted  at  venkat.rao@dau.mil. 
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